Scan-skip test goes blind if the call chain grows 3 frames (#707) - #708

Round-1 review of #706 approved the carry but flagged that none of the
four stranded fixes was pinned by a committed test, plus two @ref nits.

- Add three tests to test/core/cache-retention-maintenance.test.js, in
  the foreign-sorted-replace block:
  - `totalRebaselined === 1` on a re-baselining run, and `=== 0` once
    converged (pins the MaintenanceReport symmetry fix).
  - a capturing TracerProvider asserting the maintenance.partition span
    carries `rebaselined: true` (pins the span-attribute fix).
  - a partition already due for compaction: assert the resettle
    candidate's data file is read once, not twice, by spying on
    `fs.readFileSync` (pins the scan-skip fix). hasResettleCandidate's
    return value is otherwise unobservable once compactionDue is true
    (it's discarded via `||`), so this is the cheapest honest signal
    available; each new test was verified to fail when its
    corresponding fix is reverted.
- Retarget the scan-skip gate's @ref from LLP 0207#foreign-replace to
  #outranks-resettle: the gloss ("recognition ... still outranks it")
  is that anchor's actual subject, not the recognition test's.
- Drop the @ref on the span-attribute comment: #re-baseline settles the
  cursor-write shape, not telemetry, so citing it was close to
  mechanical. The prose rationale stays; it's the useful part.
- Amend the PR body's claim about item 1: `needsCompaction` (pure,
  read-only) is now evaluated unconditionally in the re-settle path
  where the old `||` short-circuited past it, so more moved than "only
  the scan's side effect is skipped."

Co-Authored-By: Claude <noreply@anthropic.com>

- test/core/cache-retention-maintenance.test.js: the resettle-scan-skip
  test asserted a global .parquet readFileSync count of 1 for the whole
  maintainCache tick, not just reads the gate governs. Any future second
  legitimate read elsewhere in the tick would break it with a message
  that misdirects the next reader. Switch to capturing a stack trace per
  .parquet read and asserting none pass through hasResettleCandidate,
  attributing each read to its caller instead of counting tick-wide.
  Verified both directions: passes at this head (3x, no flake), and
  fails with the expected message when the !compactionDue && gate in
  src/core/cache/maintenance.js is reverted, showing hasResettleCandidate
  in the offending stack.
- PR body: item 2's exemplar list cited llp/0012:9, 0017:9, 0036:9,
  0041:8, 0191:9 as using the linked-and-glossed Extended-by form,
  but only 0191 actually carries a link; the other four are gloss-only.
  Replaced with docs confirmed to use the linked form: llp/0106:9,
  0129:9, 0158:9, 0180:9, 0182:9, 0188:9, 0190:9, 0191:9. (0201, also
  suggested, only has a backward "Extends" pointer, not "Extended-by",
  so it was excluded.)

Co-Authored-By: Claude <noreply@anthropic.com>

`a partition already due for compaction skips the resettle-candidate row
scan` attributes each `.parquet` read to its caller by capturing
`new Error().stack` inside a `readFileSync` mock and asserting no stack
passes through `hasResettleCandidate`. The discriminating frame sits at
frame 8 of 10, and `Error.stackTraceLimit` defaults to 10. Three more
frames anywhere between the mock and the caller (an icebird refactor,
extra node:test mock internals, a wrapper in `resolver.js`) drop that
frame, and a negative "no stack mentions X" assertion then passes
vacuously: the test stays green even with the `!compactionDue &&` gate
reverted. The `stacks.length > 0` sanity check only proved a read
happened, not that the stacks were attributable, and the
`new Error().stack ?? ''` fallback would store an unattributable empty
string without complaint.

Demonstrated by running with `Error.stackTraceLimit = 7` (standing in for
the three extra frames) and the gate reverted: the old test passed.

Two guards, because they cover different routes to the same blindness:

1. Raise `Error.stackTraceLimit` to 50 while the mock is installed,
   restoring the previous value in the existing `finally` so it is put
   back even if the test throws. This removes the practical hazard.
2. Assert positively that some captured stack names `compactGeneration`,
   the legitimate reader. It calls `scanRowsFromTable` from exactly the
   same depth as `hasResettleCandidate` does, so any truncation deep
   enough to hide the frame the negative assertion hunts for also hides
   this one and fails the test loudly. Asserting on `scanRowsFromTable`
   itself would not work: it sits one frame shallower and survives
   truncation that has already blinded the real check. This guard also
   catches the empty-string fallback.

Under the same truncation with the gate still reverted, the hardened
test fails; with the gate restored it passes, truncated or not.

No production code changed.

Co-Authored-By: Claude <noreply@anthropic.com>